IBIS Macromodel Task Group Meeting date: 21 April 2020 Members (asterisk for those attending): Achronix Semiconductor Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Stephen Slater Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Fangyi to send out the updated version of the BIRD_DQ_DQS_Clocking (draft 2) to the ATM list. - Done. - Arpad to email Steve Parker asking him to post Fangyi's document to the ATM work archives. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the April 14 meeting. Curtis moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: Agenda Cleanup: Arpad asked if item #9 (BIRD201 discussion) could be removed. Walter said it could, since BIRD201 had been submitted to the Open Forum and a vote was already scheduled for the upcoming Open Forum meeting. Arpad asked if item #7 (DDR clock forwarding BIRD draft) could be removed, since Fangyi's and Walter's proposals had merged and could be handled by item #6. Fangyi agreed. Gap in IBIS for sampling with statistical mode AMI Models: Walter said that he had spoken with Hansel that morning and thought he would attend the meeting. Discussion was deferred until Hansel could attend. DDR clock forwarding BIRD draft: Fangyi shared the BIRD_DQ_DQS_Clocking_Draft_2 he had sent out after last week's meeting. Fangyi noted some cleanup modifications to the Definition of the Issue section, particularly the two scenario examples. Arpad asked about the examples using DQ and DQS instead of the generic Clock and Data terminology. Walter, Fangyi and Michael noted that the BIRD text itself uses the more general Clock and Data terminology, and this is mentioned in the last sentence of the section. The illustrative example scenarios in the section are based on DDR5. Fangyi noted that he had replaced "DLL" with "executable model". In scenario 2, the path delay from the DQS pad to the DQ latch is different for each DQ latch. Fangyi noted that the example of a possible solution uses one DQS model with a common path delay experienced by all DQs. Each bit could then have its own DQ model that would accommodate the different additional DQS path delay for that bit. Michael said that the first part of the possible solution, a common DQS model, implied one model and one instance of that model. However, the second part, with different DQ models for each bit, implied unique DQ models not just multiple instances of the same DQ model. Radek said each DQ could have a separate instance of the same model. Michael said that the proposed solution required separate models if different DQ delays were handled by each. Randy said this is where it can get messy if you intend to use different .ami files for each DQ, as you would have to wrap each in a separate [Model] for each DQ. Walter said that given one DQ and one DQS it all depends on the number of clock trees between the DQS and the DQ latch. There are many types of configurations for this. The basic executable model functionality would be the same. The only difference is the depth of the clock tree. One could have a single executable model for the DQ and another for the DQS, and an AMI parameter in the DQ or DQS model could be used to specify the depth of the clock tree. This would be a different approach that wouldn't require a separate model for each depth level of a clock tree. Fangyi agreed that there were many ways to implement a model. For this section, which is just an introduction to the BIRD, we should simply list a few possible solutions and indicate that the process is flexible. One simple approach is for each DQ to have its own [Model]. Another approach would be for the DQs to share a common executable model but use different delay parameter values. Michael suggested that the simple example should start from a Pin list point of view. He said the example would need to address the issues in scenario #2. He noted that there's an implicit connectivity in this flow, and we might want a figure to illustrate what the path/tree looks like. The model maker's perspective on the connectivity might not quite be the same as what the data flow would look like in the simulation. Fangyi said the connectivity could be addressed via a "DQ_Index" parameter that specified which DQ was being simulated. Michael said an example would be a good way for us to formulate a structure. He said there are currently gaps in defining the implementation of this multiple- model flow and structure. The system flow for this has to integrate multiple buffers (clock and data), and we haven't had to do that before. We may want to create a topic wish list of things we need to define to make this work. We may need a new parameter in AMI to support this. There may be quality assurance aspects to correctly modeling this that IBIS should not and cannot touch upon. Michael said he might be able to present a few slides on this topic at a future meeting. Randy agreed that this BIRD doesn't have to address all of these issues, but we have to think about them. Walter noted that his tool utilized a timing model that captured the set up and hold relationship between a given DQS and DQ. For memory this is pretty simple, since there's typically only one DQS per chip. On the controller, it can be a real mess. You might have 64 DQSs and 4*64 DQs that go with them. We need to know the relationship of each DQ with its DQS. Walter asked if Michael's point was that we need to understand that relationship. Michael said that we needed that as a minimum. Michael said the end user has no way of knowing a priori what that relationship is. The model maker does know this, but we need a way to convey it to the user or EDA tool. Walter said you'd have a model maker for the DQ and the DQS, and then the IBIS file would provide the connectivity (it's not in the executable model). However, this is a component level relationship that IBIS doesn't currently convey. Michael said that might be the first thing we need to add after this BIRD. Fangyi said this BIRD was dealing with the buffer level models. Walter proposed an example of 2 different chips that would use the same DQ and DQS .dlls. One chip has a two-level clock tree and one has a four-level clock tree. He said the models could use the same .dll, but the DQS model on the two- level clock tree part might have a Model_Specific In parameter called "tree_level" that is set to 2. The model for the four-level tree part might have the same parameter set to 4. Randy said this was a reasonable scenario, but the next step would be to define how the proper value of that parameter is passed in. Randy said the process would break down if you want to pass in a a value that's unique to each DQ while sharing a single executable model. Walter said each DQ could point to a different IBIS [Model], and each of them would use the same .dll but a different .ami file (with a different value for the parameter). Randy said that is possible, but it leads to an explosion in the number of Models and Model Selectors. Randy said the analog portions of the model (on-die termination, etc.), would likely be the same for all DQs, but we'd need some sort of "DQ_index" type AMI parameter that's tied to the DQ index. Walter proposed a possible solution that could involve a new BIRD. He suggested we might add a new Reserved parameter used to pass in the pin name or pin number or signal_name from the IBIS file. The EDA tool could pass it in, and the model could use it to tell whether it's dealing with DQ1, DQ2, etc. Fangyi agreed. The group then discussed changes that were more editorial in nature. Bob and Randy noted that the allowable values of Rx_Use_Clock_Input ("None", "Times", and "Waves") should be enumerated in the Usage Rules section and not as part of the Format. Radek suggested we refer to the "content" of the clock_times input not the "data type". Arpad said describing the contents as "empty" (in the case of "None") might be confusing. Fangyi suggested we state that the contents are "ignored" in this case. Ambrish asked if "ignored" was the right term to use. Radek and Curtis thought that stating that the contents would be ignored in the "None" case was correct. They said that in IBIS 7.0, clock_times is only used as an output by the model, and the EDA tool is only responsible for making sure that enough memory has been allocated to clock_times for the model to return the clock ticks. Any data in clock_times when the model is called is ignored by the model in the "None" case (or in IBIS 7.0). Radek suggested we remove the pointer-style "*" from clock_times and wave output throughout the draft text. Fangyi made the changes to the draft. Randy moved to submit the modified version to the Open Forum. Fangyi seconded. There were no objections. - Michael: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. AR: Fangyi to send the modified DQ DQS draft to Randy to be submitted to the Open Forum as a BIRD. ------------- Next meeting: 28 April 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives